よくわかるAmazon CloudSearchに行ってきました #cloudsearch

#Amazon CloudSearch

#AWS

Satoshi Noto

2014.05.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

5月15日 AWSプロダクトシリーズ｜よくわかるAmazon CloudSearchに行ってきました。

Build a Scalable Search Engine With Amazon CloudSearch by Jon Handler

Build a Scalable Search Engine With Amazon CloudSearch by Jon Handler from Eiji Shinohara

CloudSearchの開発者であるJonさんのセッションです。前半は検索エンジンシステムの概要について、後半はCloudSearchについての説明でした。最初は英語が聞き取れるか不安だったのですが、アマゾン篠原さんが通訳しつつ進めてくれたため、Jonさんの非常に聞き取りやすい英語を聞き逃しても安心という万全の体制のセッションでした。本編はボリュームが多いため、スライドに載っていないQAについて書いておきます。

Q. ランキングはパーティション全体で横断検索になるか？
A. パーティション全体で横断検索する。
Q. 横断検索できるようにしているということは上限があるのでは？
A. 影響はあるが短いレイテンシーで返せるようにしている。また、実際にどの程度のレスポンスとなるかはテストして欲しい。
Q. ステミングなどのリミテーションは？
A. 制限はあるが制限緩和可能。
Q. N-gramは使える？形態素解析を変えられる？
A. 今はないけど要望はたくさんもらっている。
Q. 辞書の性能が悪いとつらいが、辞書のカスタマイズは可能？
A. 現状はできない。
Q. 言語の認識。日本語の文書は英語や多言語が混ざっているがどうしているのか？
A. 言語指定はフィールド単位でユーザー側で指定する。
Q. Webのクローラーはついていない？推奨はある？
A. Apache Nutch。簡単に使える。

Expectation for CloudSearch

Expectation for cloudSearch from Minoru Osuka

Apache ManifoldCFコミッターでもある、Yahoo Japanの大須賀さんからCloudSearchに期待する機能についてというセッションでした。

コンサルタント時代の経験。検索エンジンを導入すると、最初にお客様は喜ぶが、すぐに検索結果の精度について関心が移る。なせこの検索結果になるのか、期待したものが出てこないといった。そのため、辞書のメンテナンスやデバッグ機能が欲しい。
せっかくAWSなのでEMRやKinesisとの連携も欲しい。機械学習とかもさせたい。
エンタープライズでの利用を考えるとACLが欲しい。役員しか見れないドキュメントであってもクローリング自体は管理者アカウントで行うため、全ドキュメントのインデックスが出来る。すると一般職で実際にファイルは開けなくともタイトルやサマリーが検索結果として見えてしまいかねない。

Impression of using CloudSearch by Takumi Yoshida

10年ぐらい検索周りをやっているという吉田さん(@yoshi0309)がCloudSearchを触ってみての感想というセッションでした。

4つのいいところ
- いけてるUI。10分でセットアップできる！
- オートスケール
- 複数ドメイン/複数スキーマ
- LuceneとSolrのDisMaxクエリをサポートしているのでSolrからの移行がしやすい
お値段もリーズナブル。よくあるような構成でシュミレーションしたら月20万。国内のASPの検索サービスは月40万〜とかで、しかも台数固定で柔軟にスケールアウトは出来ない。
注意点としては1ドキュメント毎にインデックスを更新しない。インデックス更新のAPIコール毎に課金されるため、なるべく複数のドキュメントをまとめて投入する。
ニコニコ大百科のデータで試したら、微妙な検索結果になった。「これくしょん」で検索したら「く」のみでマッチした。
スパイクに対応して欲しい。暖機運転申請可能になれば。
VPCに対応して欲しい。セキュリティグループを使いたい。インターネット経由ということでお客さんが不安がることも考えられる。
Apache ManifoldCFのコネクター開発中。早ければ今年8月にはリリース！

SnapDish&CloudSearch@aws

SnapDish&CloudSearch@aws from Fumikazu Kiyota

ヴァズ株式会社の清田さんからSnapDishでCloudSearchを利用してみてというセッションでした。

CloudSearchを利用したのは構築まではやってられないというのがあった。また、アプリとしても写真がメインであることもあり、そこまで精度が求められていないというのがある。
精度を出すため、CloudSearchに入れる手前で自前でトークナイズしたりフィルタリングしたりしている。
更新はAPIコール数で課金されるため、SQSでバッファリングしてバッチサーバーから一定サイズで書き込むようにしている。
旧APIを利用している。移行も計画しているが暫くは残しておいて欲しい。

懇親会

運良くJonさんの近くに座れたので、いくつか質問させてもらいました。なお、私は英語を話せないのでスマートインサイト株式会社の万代さんに通訳して頂きました。

Q. Solrベースになったが、トランザクションはサポートしないのか？
A. サポートしない。そもそも検索なのでトランザクション要らないのでは。
Q. インデックスに書き込んでから反映されるまでのタイムラグは？
A. サイズ（ドキュメント数）に関係なく平均10秒。むしろ、耐障害性や一貫性を重視している。

感想など

3年ほど前に少しだけSolrを触ったことがあるぐらいで、CloudSearchもざっくりドキュメントに目を通したぐらいで臨んだのですが、非常に勉強になりました。現時点のCloudSearchに出来ること、出来ないこともよく分かりましたし、製品として耐障害性やオートスケールという部分を重視していることも分かりました（これは他のAWSのマネージドサービスにも言えることですよね）。検索エンジンの導入すると必ずユーザー様と精度について話すことになること。また、クローラーやACLをどうするか。CloudSearchに機能が足りなければ外側でトークナイズして補えばよいというのも発見でした。主催者、発表者、参加者の皆さま、ありがとうございましたー！